На сайте проекта VMware Labs появилась очередная полезность - набор утилит Horizon Cloud Pod Architecture Tools. Он предназначен для того, чтобы улучшить исполнение команд назначения глобальных прав доступа.
Как знают администраторы VMware Horizon, инфраструктура распределенных узлов cloud pod architecture (CPA) имеет в своем составе команды lmvutil, которые позволяют управлять назначением глобальных прав к базе данных через интерфейс командной строки. Теперь для lmvtools сделали обертку (wrapper), которая позволяет вводить пароль только один раз и далее исполнять команды управления назначением прав. Также теперь можно экспортировать всю конфигурацию сайта, мапинги сайт-узел (site-pod), глобальные назначения (в том числе пользователей и пулов), настройки home site overrides, а также резервную копию назначений прав в файл.
Сам command builder имеет встроенный механизм для того, чтобы можно было убрать устаревшие глобальные назначения пользователей (если из больше нет в Active Directory) и назначения домашнего сайта. В этом плане в утилитах есть следующие особенности:
Опция генерации отчета в CSV со всеми пулами узлов и их ассоциированными назначениями прав.
Исполнитель команд lmvtools позволяет автоматизировать выполнение команд из файла без необходимости повторять пароль для каждой команды.
Утилиты можно использовать для следующих сценариев:
Бэкап и импорт глобальных назначений прав для любых версий Horizon 7.x.
Данные, экспортированные из узлов с Horizon версий 7.x, могут быть импортированы на любую более высокую версию (например, в другой датацентр).
Генерация отчета в формате CSV о глобальных назначениях прав и ассоциированной информации о пулах. Отчет выглядит следующим образом:
Шаблон команд по назначению глобальных прав может быть создан с использованием стандартной утилиты lmvutil. Это позволяет импортировать данные назад, в любое окружение Horizon.
Автоматическая зачистка устаревших данных пользователей. Пользователи, которых нет в AD при импорте игнорируются - это позволяет получить только актуальных пользователей и их права на выходе работы утилиты.
Экспорт локального или глобального файла AD LDS LDIF.
Больше деталей об использовании утилит Horizon Cloud Pod Architecture Tools можно узнать из этого документа. Скачать их можно по этой ссылке. Таги: VMware, Labs, Horizon, Cloud, Security
Как все уже знают, недавно компания VMware выпустила обновление своей флагманской платформы VMware vSphere 7. Одновременно с этим были выпущены новые версии и других продуктов серверной и десктопной линеек.
Сегодня мы поговорим об особенностях управления сертификатами в обновленной инфраструктуре vSphere 7. Во-первых, сертификаты Solution User Certificates были заменены на VMCA Certificates (Intermediate CA), что сильно упростило управление инфраструктурой сертификатов для виртуальной среды:
Второй полезный момент - это интерфейс REST API для обработки сертификатов vCenter Server как часть общей стратегии по управлению всеми аспектами vSphere через API:
Также в vCenter Server и ESXi было сделано много улучшений, чтобы снизить число необходимых сертификатов для случаев, когда вы управляете ими вручную, либо автоматически с помощью центра сертификации VMware Certificate Authority (VMCA), который является частью vCenter.
VMCA - это полностью автономный и самодостаточный компонент для управления сертификатами для защищенной шифрованием виртуальной среды, исключая собственно сами сервисы и приложения в виртуальных машинах (для этого уже нужна инфраструктура PKI, в этом отличие VMCA от обычного CA).
В инфраструктуре vSphere 7 есть 4 способа управления сертификатами:
Fully Managed Mode - в этом случае на vCenter есть VMCA с новым корневым сертификатом. Этот режим используется для управления сертификатами внутри кластеров (защита коммуникации между хостами ESXi, а также между ESXi и vCenter). Для этого используются так называемые Machine Certificates. Сертификат VMCA root CA certificate можно загрузить с главной веб-страницы vCenter и импортировать его на свой компьютер для настройки траста. Также можно перегенерировать корневой VMCA-сертификат на базе собственной информации вместо дефолтной (вроде "VMware Engineering" и т.п.).
Hybrid Mode - если у вас слишком много пользователей, которые управляют элементами инфраструктуры vSphere, может оказаться непрактичным заставлять всех их импортировать корневые сертификаты на свои машины. Вместо этого вы можете заменить сертификат, который использует vSphere Client, чтобы браузеры принимали его по умолчанию. Однако администраторы vSphere могут по-прежнему хотеть импортировать корневой сертификат VMCA в целях настройки траста с хостами ESXi, чьи управляющие интерфейсы могут иметь сертификаты, подписанные со стороны VMCA. Как правило, команда администраторов не такая большая, поэтому для этого не требуется много усилий.
Надо понимать, что ни в режиме Fully Managed Mode, ни в Hybrid Mode не используются самоподписанные сертификаты. Все эти сертификаты подписаны со стороны VMCA как центра сертификации. Доверяя VMCA, мы безоговорочно доверяем и серверу VMware vCenter, что надо учитывать при планировании защиты виртуальной инфраструктуры.
Subordinate CA Mode - в этом режиме VMCA может оперировать как подчиненный центр сертификации, подчиняясь корпоративному CA. В этом режиме vCenter продолжает выполнять функции по автоматизации управления сертификатами как в режиме Fully Managed Mode, за исключением того, что они генерируются на стороне корпоративного центра сертификации. В этом случае надо уделять внимание процессу передачи сертификатов со стороны корпоративного CA на vCenter, так как в это время может произойти их подмена со стороны злоумышленника. Поэтому даже крупные организации, как правило, используют режим Hybrid Mode.
Full Custom Mode - в этом случае VMCA не используется для управления сертификатами, а администратор в ручном режиме занимается их генерацией и импортом. Это весьма экзотический сценарий, так как в этом случае придется управлять десятками и даже сотнями сертификатов, в зависимости от размера инфраструктуры. Это рождает большую вероятность человеческой ошибки. Возможно, этот вариант применим для каких-то особо секретных инфраструктур, где доверие людям больше, чем доверие ИТ-системам.
VMware в своей статье про сертификаты для vSphere 7 однозначно рекомендует использовать режим Hybrid Mode, если к нему в вашей инфраструктуре нет каких-либо противопоказаний или ограничений.
Как все уже знают, в скором времени компания VMware сделает доступной для загрузки обновленную платформу виртуализации VMware vSphere 7. О новых возможностях этого решения мы уже писали, а также рассказывали об отдельных улучшениях подробнее (например, о новом DRS).
Сегодня мы поговорим о службах Identity Federation, появившихся в VMware vSphere 7.
В современном мире в корпоративной инфраструктуре все чаще отходят от устаревшей аутентификации по паролям и переходят к практикам двухфакторной (2FA) или многофакторной (MFA) аутентификации. Процесс идентификации пользователей всегда основан на 3 ключевых вещах: что-то вы знаете (пароль), что-то у вас есть (телефон) или кем-то вы являетесь (отпечаток пальца).
Службы Identity Federation позволяют объединить инфраструктуру vCenter Server с другими Identity Providers, такими как Active Directory Federation Services (ADFS), в целях унификации процесса двух- или многофакторной авторизации. Иными словами, пользователи, логинящиеся через 2FA в свой десктоп или в облачный сервис, будут использовать ту же самую процедуру и для операций с vCenter Server.
Будучи подключенным к одному из провайдеров аутентификации (например, ADFS), клиент vSphere Client при логине будет перенаправлять на форму логина данного провайдера. После авторизации на стороне провайдера будет произведено обратное перенаправление с использованием защищенного токена, через который пользователь уже будет работать со службами vCenter.
С точки зрения пользовательского опыта это напоминает, например, логин на веб-сайт с помощью Google или Facebook. Для обмена информацией используются протоколы OAUTH2 и OIDC.
Если вы включите Identity Federation, вы сможете пользоваться традиционными службами Active Directory, Integrated Windows Authentication и LDAP/LDAPS для аутентификации в vCenter Server. Однако надо понимать, что все эти методы аутентификации не затрагивают vSphere Single Sign-on (SSO), который, по-прежнему, используется для внесения административных настроек в саму платформу vSphere.
Более подробно об этом механизме рассказывает Bob Plankers в видео ниже:
Это гостевой пост нашего спонсора - компании ИТ-ГРАД, предоставляющей виртуальную инфраструктуру VMware в аренду. Если ваша компания обрабатывает, хранит или передает данные платежных карт, значит она попадает под требования стандарта PCI DSS и должна пройти сертификацию. Но этот процесс можно значительно упростить, если часть ответственности за ежегодный аудит и аттестацию возьмет на себя облачный провайдер, который предоставил услугу «PCI DSS в облаке».
На сайте проекта VMware Labs появилась очередная интересная штука - утилита Pallas. Нужна она тем, у кого серверы ESXi находятся в изолированной относительно средств vCenter управления среде (за сетевыми экранами и далеко).
Понадобиться, например, это может в следующих случаях:
У вас несколько хостов ESXi, которые работают в полностью изолированной сети, но у вас есть требование по управлению ими из публичной сети.
Ваш хост ESXi не имеет кабельного соединения с сетью и должен быть подключен через WiFi или мобильное подключение. Например, ESXi работает на нефтяной вышке или в вагоне поезда, а вам нужно безопасно управлять этим хостом с сервера vCenter.
Ваш ESXi работает на IoT-компьютере (edge-девайс), а вам нужно удаленное управление таким хостом (патчинг, создание ВМ и т.п.).
Для этих целей создается специальная агентская виртуальная машина (Dominate agent VM), в которую напрямую (через pass-through) пробрасывается устройство, которое дает интернет (например, LTE-модем). Такая ВМ уже, в свою очередь, взаимодействует с хостом через ESXi SDK для выполнения функций управления (например, передача команд по развертыванию новой ВМ).
Эта машина взаимодействует уже с Pallas Manager через протокол MQTT, который не разрешает любые входящие соединения, то есть инфраструктура оказывается защищенной от доступа извне. Больше деталей об этом продукте можно узнать из видео ниже:
Документация по проекту Pallas находится здесь (просто выберите PDF из комбо-бокса загрузки), а скачать сам виртуальный модуль в формате OVA можно по этой же ссылке.
На днях компания Intel опубликовала руководство по безопасности Security Advisory INTEL-SA-00329, в котором описаны новые обнаруженные уязвимости в CPU, названные L1D Eviction Sampling (она же "CacheOut") и Vector Register Sampling. Прежде всего, надо отметить, что обе этих уязвимости свежие, а значит исправления для них пока не выпущено.
Соответственно, VMware также не может выпустить апдейт, пока нет обновления микрокода CPU от Intel. Когда Intel сделает это, VMware сразу выпустит патч, накатив который на VMware vSphere вы избавитесь от этих потенциальных уязвимостей.
Vector Register Sampling (CVE-2020-0548). Эта уязвимость является пережитком бага, найденного в подсистеме безопасности в ноябре прошлого года. Она связана с атаками типа side-channel, о которых мы писали вот тут. В рамках данной атаки можно использовать механизм Transactional Synchronization Extensions (TSX), представленный в процессорах Cascade Lake. О прошлой подобной уязвимости можно почитать вот тут. А список подверженных уязвимости процессоров Intel можно найти тут.
L1D Eviction Sampling (CVE-2020-0549). Эта уязвимость (ее также называют CacheOut) позволяет злоумышленнику, имеющему доступ к гостевой ОС, получить доступ к данным из памяти других виртуальных машин. Более подробно об уязвимостях данного типа можно почитать на специальном веб-сайте. Также вот тут находится список уязвимых процессоров.
Следите за обновлениями VMware, патчи будут доступны сразу, как только Intel обновит микрокод процессоров. Достаточно будет просто накатить обновления vSphere - и они пофиксят уязвимости CPU.
Таги: VMware, Intel, Security, VMachines, vSphere, CPU
Недавно компания Microsoft объявила о том, что мартовские обновления Windows в этом году затронут поведение серверов Microsoft LDAP (доменных контроллеров), которые являются частью сервисов Active Directory. Эти изменения заключаются в том, что теперь механизмы LDAP channel binding и LDAP signing будут включаться по умолчанию, а для уже существующих инсталляций дефолтные настройки изменятся. На это обратил внимание один из наших читателей, который дал ссылку на соответствующую статью коллег из компании VMware.
В целом, инициатива эта позитивная - она согласуется с оповещением безопасности CVE-2017-8563, которое говорит о том, что незащищенная коммуникация LDAP может быть скомпрометирована. Поэтому, начиная с марта, любая LDAP-коммуникация, которая не использует TLS, потенциально может быть отвергнута Windows-системой. Почитайте, кстати, об этой суете на Reddit.
Это, конечно же, затрагивает и платформу VMware vSphere, компоненты которой могут использовать как обычный протокол LDAP (ldap://), так и защищенный LDAPS (ldaps://) для соединения со службами Active Directory. Также VMware vSphere поддерживает и механизм аутентификации Integrated Windows Authentication (IWA), который не затрагивают грядущие изменения.
Если вы уже настроили ваш vCenter Server для доступа к Active Directory через LDAP с TLS (LDAPS) или через механизм IWA, то вам не стоит бояться обновлений (если эти соединения идут не через балансировщики или прокси-серверы).
Проверить текущую интеграцию с LDAP в vCenter можно в разделе Configuration -> Identity Sources:
Как мы видим из трех источников идентификации по ldap только один использует TLS и будет работать после апдейтов, а вот первые два источника требуют перенастройки.
После мартовских обновлений при логине в vSphere Client через аккаунты Active Directory вы можете получить вот такую ошибку:
Invalid Credentials
При попытке добавить или изменить Identity Source в vCenter вы получите вот такую ошибку:
Check the network settings to make sure you have network access to the identity source
Поэтому попытаться сделать нужные настройки (хотя бы в изолированной от производственного окружения среде) нужно уже сейчас. Тем более, что vCenter позволяет одновременно использовать несколько Identity Sources.
Для того, чтобы настроить и протестировать LDAP Channel Binding & Signing можно использовать следующие материалы:
Документ о настройке LDAP Signing в Windows Server 2008 говорит, что вам надо изменить групповую политику "Default Domain Policy" (для домена), а также "Default Domain Controllers Policy" (для контроллеров домена), после чего дождаться ее обновления или обновить ее командой gpupdate /force.
Надо понимать, что обновление этих политик затронет не только инфраструктуру VMware vSphere, но и все остальные сервисы, использующие LDAP, поэтому процесс этот нужно тщательно спланировать. Кстати, если вы это будете делать для виртуальных машин с контроллерами домена в тестовой конфигурации, то можно сделать снапшот всего тестового окружения перед изменением конфигурации, чтобы откатиться к ним в случае, если вы что-то не предусмотрели (для производственной среды снапшоты контроллеров домена делать не стоит).
Чтобы проверить, что политики применились, можно использовать встроенную утилиту Windows ldp.exe. Запустите ее на контроллере домена и укажите адрес localhost и порт 389:
Дальше идите в меню Connection утилиты и выберите там пункт Bind, где нужно ввести креды доменного администратора и выбрать вариант Simple bind:
После этого вы должны увидеть ошибку "Error 0x2028 A more secure authentication method is required for this server", которая говорит о том, что вы корректно отключили все небезопасные байндинги LDAP:
Если вы не получили такой ошибки, то значит настройки у вас еще не применились, и их надо проверить.
О настройке сервера vCenter для LDAPS рассказано вот тут. Единственное, что вам потребуется - это добавить рутовый сертификат для сервера vCenter, который можно вывести следующей командой (если под Windows надо будет поставить Open SSL, под Linux утилита уже встроена):
Далее скопируйте все данные между "—–BEGIN CERTIFICATE—" и "—–END CERTIFICATE—–", после чего сохраните это в текстовый файл.
Никакой срочности до марта нет, поэтому не нужно суетиться и обновлять все Identity Sources, но разрабатывать план по переходу на LDAPS и тестировать его нужно уже сейчас. Будет неприятно, если пользователи неожиданно столкнутся с проблемой аутентификации. И да, откладывать обновления Windows не вариант - это единственный способ своевременно закрывать дырки в сфере информационной безопасности для вашей компании.
Мы не раз упоминали средство VMware AppDefense, которое позволяет защищать виртуальную инфраструктуру vSphere за счет наблюдения за нормальной сетевой активностью приложений и выявления подозрительных отклонений, вызываемых вредоносным ПО. Напомним, что решение AppDefense входит в состав VMware vSphere Platinum.
На днях компания VMware выпустила обновленный AppDefense 2.3, где появилась масса новых возможностей. Давайте на них посмотрим:
1. Действие Process Kill как ответ на возникшую угрозу.
Ранее в качестве ответной реакции на выявленное отклонение можно было использовать действия выключения ВМ, создание снапшота или приостановка машины (suspend). Теперь же есть возможность завершить любой из подозрительных процессов внутри гостевой ОС:
2. Поведенческие отметки времени (Behavior Timestamps).
В рамках концепции выдачи только необходимых привилегий пользователям или процессам для исполнения своих задач, AppDefense позволяет отслеживать какой сервис как себя вел и, главное, когда в последний раз это происходило (для этого есть поле last seen):
Все это очень помогает при ретроспективном анализе безопасности и аудите происходивших событий.
3. Улучшения классификации алертов и приведение в порядок узких мест на базе серьезности инцидентов.
Теперь алерты очень детально разделяются по степени критичности, а отсюда уже следует следующее улучшение - теперь для критичных событий можно сделать радикальные действия (выключить ВМ), а для небольших отклонений - просто оповестить администратора или отключить сервис.
4. Новые роли для AppDefense SaaS portal.
Теперь можно разделять роли еще более гранулярно и выделять пользователям портала только самые необходимые привилегии. Например, такое можно сделать для сотрудников сектора ИБ, а также команд SecOps.
5. Установка и апгрейд без перезагрузок.
Модуль AppDefense для гостевой ОС поставляется вместе с VMware Tools, что позволяет организовать очень мягкое взаимодействие с гостевой системой, не подразумевающее частых перезагрузок, даже в случае апгрейда решения. Для такого образа действий вам потребуется VMware Tools 11 или более поздняя версия пакета (где как раз встроена функция обновления AddDefense без перезагрузок).
6. Поддержка DNS для разрешенного поведения (Allowed Behaviors).
Теперь не нужно искать, для какой системы какой IP-адрес нужно использовать. Для настройки разрешенного поведения можно использовать человеческие имена сервисов из DNS.
7. Поддержка VMware NSX-T.
Теперь AppDefense может работать в комплексе с решением по агрегации и защите сетей виртуального датацентра NSX-T (в дополнение к NSX-V) для переведения виртуальных машин на карантин. Это позволяет настраивать более гранулярные ответные действия, которые AppDefense предпринимает как реакции на вредоносные действия.
8. Сканирование на уязвимости и приоритизация рисков.
Вот пример представления "AppDefense 2.3 – VM OS Vulnerabilities View", которое позволяет оценить имеющиеся слабые места ОС:
Вот уже представление "AppDefense 2.3 – VM Guest Monitoring View":
AppDefense 2.3 позволяет приоритизировать возможные риски и представить узкие места на дэшбордах, которых весьма немало в продукте.
Скачать VMware AppDefense 2.3 можно по этой ссылке. Полный список новых возможностей и изменений приведен тут.
Большинство из вас, конечно же, слышало о серии уязвимостей в процессорах Intel (например, Meltdown и Spectre), которые потенциально могли приводить к получению контроля над исполнением систем (в том числе виртуальных машин), работающих на базе определенных CPU. Об этом можно прочитать у нас, например, тут и тут.
При обнаружении таких уязвимостей Intel выпускает обновления микрокода (firmware) для своих процессоров, которые нужно применить как к серверам ESXi, так и к виртуальным машинам. Например, для устранения уязвимости типа MDS была добавлена инструкция MD_CLEAR, которую гостевая ОС может обнаружить и использовать для защиты от определенных уязвимостей.
В виртуальной среде виртуальная машина - это VMX-процесс на сервере ESXi, который обеспечивает исполнение гостевой операционной системы. При этом ВМ может перемещаться между серверами ESXi средствами vMotion, поэтому она может иметь довольно большой аптайм (больше самих хостов, где она работает) и, как следствие, долго не обновлять виртуальное аппаратное обеспечение.
В то же время, для патчинга некоторых уязвимостей нужно обновить микрокод CPU и пересоздать VMX-процесс виртуальной машины, чтобы она могла инициализировать и подхватить обновления микрокода (что происходит только при первой загрузке). Простая перезагрузка тут не поможет, так как в этом случае пересоздания VMX не происходит, а лишь идет ребут гостевой системы. Кстати, это вам на заметку - если хотите "почистить" виртуальную машину, то лучше выключить и включить ее, а не перезагружать.
Чтобы выполнить процедуру выключения и включения, начиная с vSphere 6.5 Update 3 и vSphere 6.7 Update 3, компания VMware ввела инструкцию vmx.reboot.PowerCycle, которая выполняет цикл питания виртуальной машины. Этот параметр, который можно добавить в VMX-файл, считывается со стороны VMware Tools, которые уже совместно с хостом ESXi обеспечивают исполнение этого цикла.
Чтобы добавить этот параметр в VMX-файл через PowerCLI, вы можете использовать следующую команду:
Эти команды можно сопроводить принудительным флагом исполнения -Force и контролировать поведение в случае ошибки с помощью -ErrorAction.
После того, как параметр PowerCycle будет выставлен, VMware Tools (вы же помните, что они должны быть установлены) смогут совершить цикл сброса питания для виртуальной машины, а затем сам параметр будет удален из VMX-файла. Также он будет удален автоматически, если вы вручную завершите и снова запустите виртуальную машину.
Для контроля того, что параметр установлен, вы можете посмотреть в vSphere Client, в разделе Configuration Parameters (в самом низу):
Также использование данного параметра может вам помочь в случае кластеров Enhanced vMotion Compatibility (EVC). Такие кластеры требуют от виртуальных машин поддержки единого базового уровня инструкций CPU для обеспечения vMotion между хостами с разным аппаратным обеспечением.
В случае, если у вас где-то поменялось железо на хостах, то нужно выполнить перезапуск цикла питания виртуальных машин, что приведет кластер EVC к единому базовому уровню и позволит избавиться от потенциальных проблем.
Да, все еще продолжаем рассказывать об анонсах конференции VMworld 2019. Одним из главных обновлений в части сетевой инфраструктуры стал выпуск платформы VMware NSX-T 2.5. Новые возможности продукта сосредоточены в следующих сферах:
Напомним, что это решение предназначено для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров и контейнеров приложений Kubernetes/Docker. В марте этого года мы писали о версии VMware NSX-T 2.4.
Давайте посмотрим, что нового появилось в апдейте продукта NSX-T 2.5:
1. Новый движок NSX Intelligence.
NSX Intelligence - это распределенный аналитический движок, который помогает администраторам более гранулярно контролировать аспекты сетевой защиты на всех уровнях датацентра, упростить проверку инфраструктуры с точки зрения комплаенса и ускорить выполнение процедур обеспечения безопасности.
Фишка этого движка в децентрализованности, NSX посылает команды на сразу на несколько серверов ESXi на уровень гипервизора для сбора и обработки метаданных, после чего они уже передаются на модуль NSX для визуализации и генерации отчетов.
Результатом такой аналитики является визуализация топологии приложений, рекомендации по применению политик безопасности, непрерывный мониторинг любого потока в датацентре и аудит исполнения политик безопасности. Все это доступно в рамках единой консоли NSX:
2. Улучшения механизма работы в гибридной среде (Hybrid Cloud Networking).
Онпремизный продукт NSX Data Center интегрируется с решением NSX Cloud, что позволяет создать единую среду применения политик безопасности, вне зависимости от того, где находится в данный момент виртуальная машина с приложением - в собственном датацентре или в облаке.
В версии NSX-T 2.5 появился новый режим развертывания и функционирования - Native Cloud Enforced. Он позволяет обеспечить соблюдение унифицированных политик в гибридной среде без необходимости установки агентов (NSX tools) в виртуальных машинах, а значит не создает дополнительную нагрузку на них. Эти политики через API транслируются в инфраструктуру сервис-провайдера, где они уже применяются к виртуальным машинам и приложениям средствами облачного ПО.
Этот режим реализуется в дополнение к режиму NSX Enforced, который требует установки агентов и более гранулярно следит за политиками безопасности. Каждый из режимов имеет свои преимущества и недостатки. Вот как выглядит режим Native Cloud Enforced для решения NSX Cloud on Azure:
3. Улучшения комплаенса и безопасности.
В этой категории появилось несколько важных нововведений:
Соответствие регуляции FIPS 140-2 (не актуально для России).
Поддержка L4-L7 функций распределенного фаервола (DFW), механизма Identity/User ID firewalling и белых списков FQDN/URL.
Правила Layer 7 на базе application ID в сетевом экране шлюза NSX Edge для трафика north-south.
Поддержка Layer 7 сетевой фильтрации на базе application ID в DFW для гипервизоров KVM.
VPN на уровне каждого клиента у сервис-провайдеров. Ранее IPsec-соединение поддерживалось только в шлюзах Tier 0, теперь же в целях большей изоляции VPN выделен на уровне клиента и изолируется внутри облака.
NSX-T поддерживает откидывание копий пакетов на сервисную ВМ (Service Virtual Machine, SVM), такую как Gigamon или NETSCOUT для анализа, мониторинга и сбора статистики. Это позволяет не организовывать дополнительный канал прохождения трафика через эти сервисы.
4. Улучшенные возможности операционного управления Day-2.
Здесь появилось 2 основных улучшения:
Возможность создания черновиков конфигураций DFW, к которым можно потом откатиться. Там много интересных функций, таких как возможность откатиться к предыдущей конфигурации, работа с черновиками нескольких пользователей, клонирование конфигураций, таймлайн сохраненных черновиков и т.п.
Дэшборд Capacity Monitoring. Этот дэшборд показывает текущее использование объектов (таких как логические коммутаторы, логические роутеры TO/T1, экземпляры DHCP-серверов, правила NAT) по отношению к доступным максимумам конфигурации.
Скачать решение VMware NSX-T 2.5 можно по этой ссылке. Документация доступна тут.
В апреле этого года мы писали о полезной для администраторов решения VMware App Volumes утилите App Volumes Entitlement Sync, которая доступна на сайте проекта VMware Labs. С помощью нее можно прочитать, сравнить и синхронизировать права доступа к объектам между экземплярами App Volumes на географически разделенных площадках. После аутентификации на обеих площадках вы сможете выбрать права доступа, которые надо сравнить или синхронизировать:
На днях на сайте VMware Labs эта утилита была обновлена до версии 2.2. Давайте посмотрим, что там появилось нового:
Возможность игнорировать Extra AppStacks на Primary и Secondary серверах - это могло приводить к вылету утилиты.
Возможность экспорта назначения прав для основного и резервного серверов в формат XML.
Пофикшены ошибки с отсутствующими назначениями прав на стороне источника App Stack. Если права не назначены, то отображается лейбл "No Entitlements".
Скачать App Volumes Entitlement Sync версии 2.2 можно по этой ссылке.
Некоторые из вас знают, что у VMware есть решение для организации доступа конечных пользователей к ресурсам виртуальной инфраструктуры Workspace ONE. Одним из компонентов этого решения является средство Workspace ONE Access (бывший продукт VMware Identity Manager), позволяющее организовать идентификацию и авторизацию пользователей и их устройств в инфраструктурах vSphere и Horizon.
В мае 2018 компании VMware и Octa анонсировали партнерство в области создания единой инфраструктуры по управлению интегрированной аутентификацией и авторизацией пользователей и их устройств (Unified Endpoint Management). Ну а на VMworld 2019 было рассказано о прогрессе в развитии совместных инициатив обеих компаний.
Цель сотрудничества компаний VMware и Okta - создать единую среду универсального SSO-доступа для мобильных устройств и установить доверие к ним для различных платформ на уровне виртуального датацентра.
VMware приносит здесь экспертизу по управлению мобильными устройствами и комплаенса в контексте самих устройств (на базе решений купленной когда-то компании AirWatch), а Octa берет на себя контекст управления идентификацией на уровне пользователя и SSO-интеграцию с различными системами датацентра.
Вторая важная вещь, анонсированная на VMworld 2019 - это интеграции VMware и Octa при работе со службами каталога. Теперь решение Okta Integration Network может быть добавлено в Workspace ONE Intelligent Hub, чтобы создать единую точку управления идентификацией для всех приложений и платформ.
Также функционал для работы с восстановлением идентификации без пароля (повторная авторизация с мобильного) был перенесен со стороны Octa на Workspace ONE во избежание дублирования функционала.
Помимо этого, был убран следующий дублирующийся функционал за счет его перенесения в среду Octa: мобильный SSO и политики доверия на уровне устройств (device trust policies). Теперь пользователи и назначения им прав на ресурсы централизованы в консоли Okta (только те юзеры, которые используют Octa и VMware одновременно). Там же сосредоточены политики и действия (actions).
Еще одна возможность, анонсированная на VMworld - это Workspace ONE Okta Universal Directory Integration. Теперь пользователи получат интеграцию между Workspace ONE Access (бывший VMware Identity Manager) и Okta Universal Directory (UD). Функции UD теперь позволяют могут использовать в качестве источника идентификации не только службы каталога Active Directory, но и любые другие службы, такие как HR-системы со списками сотрудников.
Это хорошо для пользователей, которые часто не включаются в состав Active Directory (сезонные или контрактные рабочие), либо нужно для тех компаний, которые по тем или иным причинам отказываются от AD.
Теперь такие пользователи являются полноценными участниками экосистемы VMware Workspace ONE, а также защищаются в рамках концепции VMware Zero Trust.
UD и Workspace ONE Access коммуницируют за счет SCIM-интеграции, а пользовательская информация передается в Workspace ONE UEM через специальный UEM API.
Кстати, об этих всех моментах написала не только VMware, на и сама Octa.
Это гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего в аренду виртуальные машины из облака по модели IaaS. Вспоминаем, кому пришлось столкнуться с неисправностями из-за проблем с Border Gateway Protocol. Приводим примечательные кейсы за последние несколько лет.
Недавно компания VMware обновила платформу виртуализации и доставки настольных ПК и приложений VMware Horizon 7.9, а также выпустила новые версии клиентов Horizon Clients 5.1 и решения User Environment Manager 9.8. Одновременно с этим была также выпущен и обновленный продукт Unified Access Gateway 3.6, предназначенный для организации шлюзов и безопасных соединений для доступа к инфраструктуре Workspace ONE и Horizon.
Напомним, что о прошлой версии VMware Unified Access Gateway (UAG) 3.5 мы писали вот тут, она вышла сразу после релиза платформы VMware Horizon 7.8.
Основные нововведения UAG 3.6 включают в себя:
Новый сервис Secure Email Gateway Edge
Возможности миграции из Tunnel Proxy на туннель для каждого из приложений (per-app Tunnel)
Множество прочих улучшений, особенно в сфере безопасности
Вот тут можно увидеть обзор компонента Secure Email Gateway (SEG) Edge Service, который позволяет защитить корпоративную почтовую инфраструктуру и открывает возможности мобильного управления Mobile Email Management (MEM) в продукте Workspace ONE UEM:
Защита почтовика заключается в том, что ограничивается список устройств на уровне Workspace ONE, которым позволено общаться с компонентами почтовой инфраструктуры.
Также с помощью специального SDK можно создавать приложения, которые будут нативно общаться с корпоративными ресурсами предприятия напрямую, в рамках собственного туннеля на уровне приложения. Описание того, как это работает, вы также найдете на видео выше (примерно, начиная с 11:27).
Такой подход позволяет задавать правила для трафика на уровне устройств, существенно повышает производительность и дает возможность поддерживать различные типы трафика (например, UDP).
Про функции OCSP stapling, которые позволяют безопасно установить достоверность SSL-сертификата путем запроса удостоверяющего центра, можно посмотреть, начиная с 13:39:
Ну а про возможности валидации артефактов SAML JWT рассказывают в районе 14:15:
Если вы хотите детальнее узнать об этих возможностях, особенно о Secure Email Gateway Edge и новых функциях безопасности Unified Access Gateway 3.6, посмотрите вот это видео:
Ну а по интерфейсу UAG 9.6 и его настройкам можно детально пройтись вот в этом ролике:
Скачать VMware Unified Access Gateway 3.6 можно по этой ссылке. Release Notes доступны тут.
Весной этого года мы писали о новой версии продукта VMware vRealize Network Insight (vRNI) 4.1, который позволяет системным и сетевым администраторам (а также администраторам информационной безопасности) наблюдать за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.
На днях VMware объявила о выпуске vRNI 4.2, давайте посмотрим, что там появилось нового.
1. Новые Data Sources
Теперь данные можно получать из следующих систем:
Fortinet Firewall
Можно получить полный доступ к средствам управления Fortinet FortiManager, который управляет сетевыми экранами FortiGate. Это позволяет видеть всю инфраструктуру в контексте фаерволов, мгновенно видеть, какие правила привязаны к ВМ, получать сетевую топологию и многое другое.
OpenShift Container Platform
В прошлой версии была добавлена поддержка VMware Enterprise PKS и ванильной инсталляции Kubernetes, а теперь поддержка была расширена функциями сетевой видимости, средствами обеспечения безопасности приложений, планирования миграции и решения проблем для небольших нагрузок.
Кастомные Data Sources
Это называется User Assisted Network Information (U-AN-I). В рамках этого механизма вы можете ввести информацию о собственном коммутаторе или маршрутизаторе, который в дальнейшем будет добавлен в список поддерживаемых устройств. Но еще до полноценной поддержки это даст вам возможность просматривать пути VM-to-VM, дэшборд для коммутатора/маршрутизатора в рамках сетевой топологии, список всех интерфейсов, маршрутов, список VRF и т.п.
Также есть Python-библиотека, которая позволит автоматизировать сбор информации с устройств (маршруты, интерфейсы и т.д.) и загрузить ее в Network Insight. Саму эту задачу можно добавить в планировщик для регулярного обновления.
2. Метрики Network Latency.
Network Insight 4.2 представляет метрику задержки в 2 формах: TCP Round-Trip Time (RTT), которая привязана к сетевому потоку и метрика latency между отдельными компонентами (виртуальные и физические адаптеры NIC в рамках хоста ESXi).
Метрика TCP RTT может быть найден на дэшборде потока:
Также можно найти все потоки, время RTT которых больше 10 мс, следующей командой в поиске:
Average Tcp RTT of flow where Average Tcp RTT > 10ms
Кроме того, есть еще один наглядный способ увидеть все сетевые потоки вашей инфраструктуры на одной странице - надо пойти в Flow Insights и выбрать диаграмму Network Performance:
Из этого представления вы сразу поймете, какие потоки отрабатывают с самой большой задержкой, после чего можно углубиться в структуру потока и понять причину, по которой эта задержка столь велика.
С точки зрения измерения latency между компонентами, сейчас доступны следующие связки: vNIC к pNIC, pNIC к vNIC и vNIC к vNIC.
Надо отметить, что для получения данной информации вам потребуется NSX Data Center for vSphere версии 6.4.5 или выше.
3. Новые функции Application Discovery.
В Network Insight 4.1 появилась возможность обнаружения приложений без использования агентов с помощью трех методов:
Использование тэгов рабочей нагрузки (workload tags)
Иморт приложений из ServiceNow CMDB
Использование паттерн наименования (naming convention)
Последний метод особенно актуален для облачных систем (например, инстансы AWS EC2), поэтому раньше пользователи должны были сами конструировать регулярные выражения, что непросто.
Теперь же в мастере application discovery wizard для этого есть Pattern Builder:
Также, начиная с vRNI 4.2, вы можете сохранять application discovery runs как шаблоны, чтобы не конструировать регулярные выражения заново, что очень удобно.
4. Улучшения дэшборда Application Dashboard.
Это лучший дэшборд vRNI, который показывает все потоки между всеми обнаруженными приложениями в вашей инфраструктуре. В версии vRNI 4.1 его возможности были несколько ограничены, теперь же каждый поток визуализуется и детализируется, когда вы увеличиваете диаграмму и масштабируете его.
При этом с увеличением конкретного компонента увеличивается степень детализации, то есть включаются все виртуальные машины, контейнеры и т.п.
Полный список улучшений и нововведений находится в Release Notes. Скачать vRealize Network Insight 4.2 можно по этой ссылке.
Не так давно мы писали об обновлении платформы VMware Cloud Foundation 3.7, которая представляет собой набор продуктов для развертывания, исполнения, мониторинга и поддержки виртуальной инфраструктуры в онпремизном датацентре.
Архитектура VCF включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия, которые желательно развертывать все вместе, но можно какие-то и опустить. Все это находится под управлением решения VMware SDDC Manager.
На днях был анонсирован еще один пакет решений - VMware Cloud Foundation Platinum. Смысл этой платформы - повышенная защищенность частных облаков, обеспечиваемая платформой виртуализации vSphere Platinum, где инфраструктура находится под наблюдением средства анализа и активной защиты - продукта AppDefense.
Он является ядром всей платформы с точки зрения безопасности и предоставляет множество возможностей, обеспечивающих защиту виртуальной инфраструктуры на различных уровнях:
Давайте посмотрим на ключевые моменты этой архитектуры:
1. Обеспечение умного подхода к безопасности.
По аналогии с vSphere Platinum и vCloud Suite Platinum, издание Platinum для VMware Cloud Foundation интегрирует решение AppDefense напрямую в гипервизор vSphere для защиты как самой платформы, так и рабочих нагрузок в виртуальных машинах. Фишка AppDefense - алгоритмы машинного обучения, которые позволяют обучиться нормальному сетевому поведению компонентов виртуального датацентра, а потом сигнализировать об отклонениях от этой модели и предпринимать некоторые шаги по активной защите инфраструктуры.
Действие AppDefense распространяется на vSphere, NSX и vSAN, что позволяет защитить все рабочие нагрузки, входящие в структуру Cloud Foundation.
2. Работа на различных уровнях в датацентре.
AppDefense не только смотрит на виртуальные машины извне, но и анализирует поведение приложений изнутри гостевых ОС, где их поведение полностью находится под наблюдением ML-алгоритмов. В этом процессе данные собираются от среды управления vCenter, а также различных средств разработки и фреймворков для управления виртуальной средой.
3. Многоуровневая защита.
AppDefense в рамках Cloud Foundation Platinum обеспечивает активную защиту на следующих уровнях:
Compute - анализ поведения ВМ на вычислительном уровне, в том числе тех, кто имеет включенные функции шифрования (VM encryption), как при хранении, так и при перемещении машин между хранилищами.
Network - решение NSX в виртуальном датацентре использует подход микросегментации и гранулярной безопасности, что полностью поддерживается рабочим процессом AppDefense (возможность перемещения политик безопасности вместе с ВМ, вне зависимости от топологии сети).
Storage - поддержка шифрования vSAN (data-at-rest encryption) на уровне кластера, а также инфраструктуры KMIP (поддерживаются такие продукты, как CloudLink, Hytrust, SafeNet, Thales и Vormetric).
Management - vCloud Suite автоматизирует рутинные операции (включая по обеспечению безопасности и мониторингу среды в реальном времени), исключая вероятность возникновения ошибок и уязвимостей по причине человеческого фактора.
Cloud Foundation Platinum - это законченное решение для гибридных виртуальных сред (частное+публичное облако под управлением одного пакета решений), где поведение всех приложений находится под наблюдением AppDefense в рамках комплексного рабочего процесса по обеспечению безопасности. Каждая из задач может выполняться пользователем с соответствующей ролью в виртуальном датацентре:
Более подробно о VMware Cloud Foundation Platinum можно узнать по этой ссылке.
Многие администраторы платформы VMware vSphere очень часто интересуются вопросом замены сертификатов для серверов ESXi в целях обеспечения безопасности. Как правило, это просто инструкции, которые не дают понимания - а зачем именно нужно менять эти сертификаты.
Недавно VMware выпустила интересную статью на тему сертификатов в vSphere и других продуктах, приведем ниже основные выдержки из нее.
1. Сертификаты - это вопрос доверия и шифрования.
При соединении с различными веб-консолями компонентов инфраструктуры VMware vSphere используется протокол HTTPS, где S означает "Secure". Инфраструктура SSL, а точнее ее последователь Transport Layer Security (TLS), использует известный в криптографии принцип открытого и закрытого ключей, который позволяет узлам, доверяющим друг другу безопасно обмениться информацией по шифрованному каналу.
TLS развивается по следующему пути:
Версия 1.0 имеет уязвимости, он небезопасен и больше не должен использоваться.
Версия 1.1 не имеет таких уязвимостей, как 1.0, но использует такие алгоритмы шифрования, как MD5 и SHA-1, которые больше не считаются безопасными.
Версия 1.2 добавляет шифрование AES, которое работает быстро и не использует небезопасные методы, сам же алгоритм использует SHA-256. На текущий момент это стандарт TLS.
Версия 1.3 не содержит слабых точек и добавляет возможности увеличения скорости соединения, этот стандарт скоро будет использоваться.
Если вы используете сертификаты vSphere, то независимо от того, какие они (самоподписанные или выданные центром сертификации) - общение между компонентами виртуальной инфраструктуры будет вестись посредством TLS с надежным шифрованием. Вопрос сертификатов тут - это всего лишь вопрос доверия: какому объекту, выпустившему сертификат, вы доверяете - это и есть Центр сертификации (он же Certificate Authority, CA).
Многие крупные компании, имеющие определенный вес (например, Microsoft) сами являются Центрами сертификации, а некоторые компании используют службы Microsoft Active Directory Certificate Services, чтобы встроить собственные CA в операционную систему и браузеры (импортируют корневые сертификаты), чтобы "научить" их доверять этим CA.
2. В VMware vSphere сертификаты используются повсеместно.
Как правило, они используются для трех целей:
Сертификаты серверов ESXi, которые выпускаются для управляющих интерфейсов на всех хост-серверах.
"Машинные" сертификаты SSL для защиты консолей, с которыми работает человек - веб-консоль vSphere Client, страница логина SSO или Platform Service Controllers (PSCs).
"Solution"-сертификаты, используемые для защиты коммуникаций со сторонними к платформе vSphere продуктам, таким как vRealize Operations Manager, vSphere Replication и другим.
Полный список компонентов, где vSphere использует сертификаты, приведен вот тут.
3. vSphere имеет собственный Центр сертификации.
Платформа vSphere из коробки поставляется с собственным CA, который используется для коммуникации между компонентами. Называется он VMware Certificate Authority (VMCA) и полностью поддерживается для vSphere как с внешним PSC, так и для vCenter Server Appliance (vCSA) со встроенным PSC.
Как только вы добавляете хост ESXi в окружение vCenter, то VMCA, работающий на уровне vCenter, выпускает новый сертификат на этот ESXi и добавляет его в хранилище сертификатов. Такая же штука происходит, когда вы настраиваете интеграцию, например, с решениями vRealize Operations Manager или VMware AppDefense.
Надо понимать, что CA от VMware - это всего лишь решение для защищенной коммуникации между серверами, которое поставляется из коробки. Ваше право - доверять этой модели или нет.
4. Есть 4 способа внедрить инфраструктуру сертификатов на платформе vSphere.
Вот они:
Использовать самоподписанные сертификаты VMCA. Вы можете просто скачать корневые сертификаты с веб-консоли vCenter, импортировать их в операционную систему клиентских машин. В этом случае при доступе к веб-консоли, например, vSphere Client у вас будет отображаться зеленый замочек.
VMCA можно сделать подчиненным или промежуточным (subordinate/ intermediate) центром сертификации, поставив его посередине между CA и конечными хостами, что даст дополнительный уровень сложности и повысит вероятность ошибки в настройке. VMware не рекомендует так делать.
Отключить VMCA и использовать собственные сертификаты для любых коммуникаций. Ваш ответственный за сертификаты должен нагенерировать запросы Certificate Signing Requests (CSR) для всех компонентов. Эти CSR-запросы вы отсылаете с CA, которому вы доверяете, получаете их подписанными, после чего устанавливаете их в ручном режиме. Это отнимает время и чревато ошибками.
Использовать гибридный подход - для хостов ESXi в их коммуникации с vCenter использовать самоподписанные VMCA сертификаты, а для веб-консолей vSphere Client и прочих использовать перевыпущенные сертификаты, которые надо установить на сервере vCenter и хостах, с которых будет управляться инфраструктура через браузер (тогда в нем появится зеленый замочек). Это самый рекомендуемый VMware вариант использования сертификатов.
5. Enterprise-сертификаты - тоже самоподписанные.
Подумайте - самоподписанными являются не только сертификаты VMCA, но и ваши корпоративные сертификаты. Если вы выпускаете эти сертификаты только на уровне своей компании, то у вас 2 точки потенциального недоверия - сторона, выпустившая сертификаты у вас в компании, а также, собственно, сам VMCA. Такая схема создает дополнительный уровень сложности администрирования, а также нарушения безопасности.
6. Не создавайте промежуточный Центр сертификации.
Если вы создаете intermediate CA (он же subordinate CA) для VMCA, превращая его в посредника, вы создаете потенциальную опасность для виртуальной инфраструктуры - если кто-то получает доступ к корпоративному центру сертификации и его парам ключей, то он может навыпускать любых сертификатов от имени VMCA и перехватывать потом любые коммуникации.
7. Можно изменять информацию для самоподписанных сертификатов CA.
С помощью утилиты Certificate Manager utility вы можете сгенерировать новый VMCA с необходимой информацией о вашей организации внутри него. Эта утилита перевыпустит все сертификаты и заменит их на всех хостах виртуальной инфраструктуры. Это хорошая опция для гибридной модели. Кстати, вы можете менять даты устаревания сертификатов, если дефолтные вас не устраивают.
8. Тестируйте инфраструктуру сертификатов перед внедрением.
Вы можете развернуть виртуальную инфраструктуру и провести все эксперименты с сертификатами в виртуальной среде, где вы можете использовать виртуальные (nested) серверы ESXi. Приятная штука в том, что вы можете создавать снапшоты виртуальных машин, а значит в случае чего - быстро откатитесь на рабочий вариант. Еще одна среда для экспериментов - это облачная инфраструктура VMware Hands-on Labs, где можно безопасно ставить любые эксперименты.
Делайте резервную копию вашего vCenter и PSC на уровне файлов через веб-консоль VAMI. Также утилитой Certificate Manager можно скопировать старый набор сертификатов перед развертыванием новых (но только один набор сертификатов, учитывайте это). Также эта процедура полностью поддерживается со стороны VMware Global Support Services.
10. Понимайте, зачем вы заморачиваетесь с заменой сертификатов.
Ответьте для себя на несколько вопросов:
Стоит ли иконка зеленого замочка в браузере всех этих заморочек?
Нужно ли всем видеть этот замочек или только команде администрирования vSphere?
Почему вы доверяете vCenter для управления всем в виртуальной инфраструктуре, но не доверяете VMCA?
В чем отличие самоподисанного сертификата вашего предприятия от самоподписанного сертификата VMCA?
Действительно ли комплаенс требует от вас кастомных CA-сертификатов?
Какова будет цена процедур по замене сертификатов в инфраструктуре vSphere во времени и деньгах?
Увеличивает или уменьшает риск итоговое решение и почему конкретно?
Начиная с VMware vSphere 6.7, компания VMware поддерживает технологию защищенной виртуализации Virtualization-Based Security (VBS). Это один из механизмов, который позволяет предоставлять пользователям более защищенные рабочие Windows-среды средствами технологий Device Guard и Credential Guard (последняя предназначена для изоляции пространства хранения учетных записей от потенциальной кражи вредоносным ПО). Эти функции очень важны для защиты, например, таких компонентов инфраструктуры, как серверы Active Directory.
Между тем, с виртуальными машинами, работающими с поддержкой данной технологии, была найдена серьезная проблема - они зависают или выпадают в синий экран смерти (BSOD) при загрузке. Баг проявляется при включенной технологии VBS (на скриншоте vSphere Client на базе HTML5 с Hardware Version 14):
Также этот баг актуален и для включенной поддержки технологии I/O MMU:
Возможность VBS доступна в Microsoft Windows 10/2016/2019, сам же баг стал проявляться, начиная с версии Windows Insider Build 18362. VMware говорит, что проблема находится на стороне Microsoft, но оба вендора совместно работают над выпуском патча для ОС.
Статья базы знаний VMware KB 68043 содержит вопросы, которые позволят вам определить, затрагивает ли вас проблема.
Помимо проверки настроек в интерфейсе vSphere Client, которые вы видите на скриншотах выше, можно использовать вот такой PowerCLI-скрипт для определения машин, которые затрагивает проблема:
После того, как вы найдете у себя такие ВМ, то выхода у вас два:
Не использовать VBS и I/O MMU для виртуальных машин.
Использовать workaround, который приведен в статье KB 68043.
Workaround заключается в следующем:
Выключаем машину и отключаем VBS и I/O MMU для нее.
Устанавливаем ОС на ВМ или обновляем ее до самых последних апдейтов.
Выключаем ВМ, выбираем в настройках "Expose hardware assisted virtualization to guest".
Включаем ВМ, в настройках включаем функцию (feature) "Hyper-V" в гостевой ОС, после чего перезагружаем машину.
Опять выключаем ВМ и включаем VBS и/или I/O MMU, после чего она уже будет нормально работать.
Помните, что такой Workaround не вечен для свежих установок, например, из образов 1903 & 19H1 DVD/ISO, так как следующее обновление потенциально может вернуть баг, который еще не пофикшен со стороны Microsoft. Имейте это в виду, когда создаете шаблоны виртуальных машин для массового развертывания. Поэтому сначала все обновляем до самой последней версии, потом уже используем Workaround выше.
Кстати, все могло бы быть и хуже) Например, уязвимость Remote Desktop Services vulnerability (CVE-2019-0708), требующая немедленного обновления не затрагивает системы с описанной проблемой выпадения в BSOD. Уязвимость с удаленным рабочим столом актуальна только для систем Windows XP, 7, Windows Server 2003, 2008 (+ R2), а баг с зависанием актуален только для более поздних Windows.
Ждем пока сделают нормальный фикс, и не надо будет плясать с Workaround'ом. А пока можете на всякий случай отключить VBS, если позволяют корпоративные политики.
На сайте проекта VMware Labs появилась новая интересная Open Source утилита - Distributed Trust Incident Reporting. Она предназначена для документирования инцидентов в сфере информационной безопасности, которое часто осуществляется на бумаге или в Excel даже в крупных компаниях. Некоторые системы имеют централизованную базу данных инцидентов с возможностью отслеживания ответных мер, принятых в качестве реакции на инцидент, но только на уровне собственного предприятия.
Текущие подходы по мнению VMware обладают рядом недостатков:
Инцидент может затронуть несколько сущностей/компаний с разной ответственностью.
Все они должны как-то отреагировать на него.
Некоторые сущности не имеют доверия к другим.
Нет одной стороны, которая отвечает за эксплуатацию всей системы с точки зрения безопасности.
Примером такого инцидента является нарушение процесса у производителя еды, в результате которого на полку розничной сети в продукт попадает опасный патоген. В этом случае следует серия звонков или писем от ритейлера к дистрибьютору, а далее к производителю, чтобы отреагировать на инцидент.
Увидеть всем сторонам процесса зафиксированный инцидент.
Позволяет всем сторонам отреагировать, как того требует ситуация и зафиксировать это.
Принимает на вход отчеты информационных систем об инцидентах.
Добавляет прозрачности между разными сущностями/организациями.
Работает это все на базе контейнеров Docker, а технологическую платформу фиксирования инцидентов предоставляют решения VMware blockchain или Ethereum blockchain.
Неясно, будет ли кто-то использовать эту систему от VMware, но, будем надеяться, она со временем интегрируется в существующую экосистему решений вендора для организации и эксплуатации виртуальной инфраструктуры на платформе vSphere.
Некоторое время назад мы писали о новых возможностях недавно вышедшего обновления платформы виртуализации VMware vSphere Platinum 6.7 Update 2. Cреди новых возможностей гипервизора там есть фича "Новые возможности планировщика CPU помогают бороться с уязвимостями типа L1TF".
Оказывается, это довольно серьезное улучшение. Надо сказать, что планировщик гипервизора side-channel aware scheduler (SCA) появился еще в прошлой версии платформы. Он закрывал уязвимость L1TF (L1 Terminal Fault) в процессорах Intel за счет того, что процессы виртуальных машин запускались только в одном треде одного физического ядра. Это позволяло нивелировать вектор атаки данного типа, но приводило к существенному снижению производительности.
Особенно это чувствовалось, когда сервер ESXi был загружен по CPU полностью, и SCA первой версии в этом случае давал до 30% хуже результат, чем без него. Если же сервер был загружен, например, на 75%, то в производительность оставалась примерно той же, но без SCA нагрузка на CPU была существенно ниже.
Итак, начиная с VMware vSphere 6.7 Update 2, появился обновленный планировщик SCAv2, который был существенно доработан по сравнению со своей предыдущей версией. Он позволяет исполнять контексты vCPU одной машины в разных гипертредах одного физического ядра процессора хоста. В этом случае атаке L1TF не подвержены взаимодействия типа VM/VM и VM/ESXi (чувствительная информация между ними не шарится в общем кэше).
В документе описано 2 типа тестов, которые проводились для планировщиков SCAv1 и SCAv2: работа хоста под максимальной нагрузкой по процессорам и под нагрузкой на уровне 75% от максимальной мощности всех CPU хоста ESXi (reduced load). В качестве базового уровня использовался планировщик без SCA (он же на картинке ниже обозначен как Default):
Если верить графикам, отражающим результаты тестирования различными бенчмарками, то планировщик SCAv2 работает существенно лучше во всех случаях, кроме очень большой (по выделенным ресурсам) виртуальной машины - Monster VM с базой Oracle и 192 vCPU, но такой кейс в реальной жизни случается весьма редко. Так что, в целом, улучшения были проведены весьма существенные (как минимум, на 11% планировщик стал более производительным по результатам тестов).
Помимо документа выше, информация об улучшениях планировщика приведена еще в KB 55806.
Некоторые администраторы решения vRealize Operations сталкиваются с трудностями восстановления админского пароля к консоли Operations Manager. В этом случае большинство использует функции сброса пароля root к виртуальному модулю, хотя у Operations Manager 7.0 есть простая процедура password recovery, правда подготовиться к ней нужно заранее.
Просто откройте vRealize Operations Manager Administration и перейдите в раздел Administrator Settings:
Как мы видим, здесь можно задать опцию восстановления пароля администратора, просто указав его почту (отправку письма со ссылкой на восстановление пароля можно протестировать).
Как только вы зададите эти настройки, у вас появится опция "Forgot password" на экране логина:
Когда вы нажмете эту ссылку, вам будет отправлено письмо на заданный ранее email со ссылкой на сброс пароля:
Перейдя по ней, вы сможете сразу установить новый пароль, не зная старого.
Ну вы поняли да, что настроить способ восстановления пароля нужно еще до того, как вы его забыли :)
Недавно компания VMware провела серию релизов своих продуктов, главным из которых было обновление платформы виртуализации VMware vSphere 6.7 Update 2. Но помимо этого, VMware обновила еще 3 своих решения из линейки по оптимизации операций датацентров:
vRealize Automation 7.6
vRealize Lifecycle Manager 2.1
vRealize Network Insight 4.1
Давайте посмотрим, что в этих продуктах появилось нового:
1. vRealize Automation 7.6.
В этом релизе VMware сделала упор на интеграцию архитектуры SDDC с платформой Cloud Management Platform (CMP):
Появилась интеграция с решением NSX - пользователи могут теперь настроить одновременно NSX-T и NSX-V для различных кластеров сети на одном сервере vCenter. Также будет добавлена поддержка on-demand private networking.
Улучшилось управление рабочими процессами в vRealize Orchestrator - теперь появились такие функции в них, как Design, Run, Content Management и Troubleshooting. Также будет добавлена поддержка нескольких клиентов (multi-tenancy) для пользователей, которые хотят позволить использовать vRO в изолированных окружениях.
Скачать vRealize Automation 7.6 скоро можно будет по этой ссылке.
2. vRealize Lifecycle Manager 2.1.
В этом обновлении было уделено внимание функциям жизненного цикла продуктов в гибридном облаке, особенно в составе пакета решений vRealize Suite. В vRealize Suite Lifecycle Manager появились следующие новые возможности:
Установка шаблонов VMware Validated Designs
Более гранулярные настройки развертывания
Возможность Multi-content capture
Управление жизненным циклом продукта VMware Identity Manager.
Улучшения пользовательского интерфейса.
Скачать vRealize Lifecycle Manager 2.1 пока нельзя, скоро он будет доступен.
3. vRealize Network Insight 4.1.
Здесь появились следующие новые возможности:
Планирование и решение проблем на базе приложений. vRNI 4.1 берет определения приложений из ServiceNow (либо их может задать пользователь с помощью регулярных выражений). Далее эти приложения появляются на соответствующих дэшбордах мониторинга.
Возможность мониторинга окружений VMware Enterprise PKS и Kubernetes. В решение vRNI были добавлены функции для управления безопасностью и конфигурации сетевого взаимодействия для приложений на PKS и Kubernetes.
Улучшенная видимость происходящих событий в датацентре с точки зрения сети. Теперь на таймлайн изменения конфигураций безопасности и сетевых настроек, включая окружения NSX, были добавлены и метки пользователей (то есть не только, что изменено, но и кто изменил). Также была добавлена поддержка балансировщиков F5 и отслеживание их физического пути трафика.
Скачать vRealize Network Insight 4.1 скоро можно будет по этой ссылке.
Полтора года назад мы писали о PowerCLI-сценарии, который решает проблему того, что права доступа пользователей (Entitlements) не синхронизированы при резервировании серверов App Volumes Managers и баз данных SQL Server на запасной площадке, что влечет за собой проблемы доступа при переключении в случае сбоя.
При этом данный скрипт не реплицировал данные томов AppStacks, которые можно перенести обычным копированием (также можно автоматизировать этот процесс за счет настройки Storage Groups, как это описано в документе "App Volumes Deployment Considerations").
На днях на сайте проекта VMware Labs появилась GUI-обертка к данному процессу, которая называется App Volumes Entitlement Sync. С помощью нее можно прочитать, сравнить и синхронизировать права доступа к объектам между экземплярами App Volumes на географически разделенных площадках:
После аутентификации на обеих площадках вы сможете выбрать права доступа, которые надо сравнить или синхронизировать:
Перед выполнением синхронизации вам покажут, что именно будет сделано на обеих площадках:
По результатам синхронизации заполняется лог:
Процесс работы с утилитой показан в видео ниже:
Скачать App Volumes Entitlement Sync можно по этой ссылке. Документация доступна тут.
На днях компания VMware анонсировала доступность новой версии своей флагманской платформы виртуализации VMware vSphere 6.7 Update 2. Напомним, что предыдущее обновление VMware vSphere 6.7 Update 1 вышло в августе прошлого года.
Давайте посмотрим, что с тех появилось нового:
1. Новое издание VMware vSphere ROBO Enterprise.
Теперь в издании для ROBO-сценариев (Remote or Branch Offices) появились следующие возможности уровня Enterprise:
DRS в режиме обслуживания (Maintenance Mode):
Доступно только для vSphere ROBO Enterprise.
Может быть использовано для автоматического перемещения ВМ между хостами (и обратно по окончании процесса). Для этого автоматически создаются правила VM-Host affinity (отслеживается, куда машины уехали перед миграцией, потом запомненные правила применяются - и машины приезжают обратно, где и были изначально).
Утилита PSC Converge tool теперь доступна в графическом интерфейсе. Об этом средстве мы писали вот тут, оно позволяет смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC.
Она дает следующие возможности:
Конвертация топологии external PSC в Embedded через GUI.
Можно выполнить шаги по выводу внешнего PSC из эксплуатации (Decomission).
Все это доступно в разделе System Configuration тонкого клиента vSphere Client (на базе HTML5).
Можно посмотреть текущую топологию PSC и vCenter в графическом или табличном виде.
В следующих релизах будет невозможно развернуть внешний PSC, поэтому с него надо уходить.
3. Улучшения резервного копирования и восстановления vCenter Server.
Здесь появилось 2 главных улучшения:
Новые протоколы, посредством которых вы можете сделать бэкап vCSA - NFS v3 и SMB.
Нотификации и алармы на успешное и неуспешное завершение задач РК. Эти алармы можно настроить подобно обычным алармам vSphere (послать email, SNMP trap или выполнить сценарий в случае успеха или неудачи).
4. Новые алармы и категории для vSphere Health.
Опция acknowledgement (заглушить) для алармов vSphere health (как и для обычных алармов).
Новые категории теперь включают в себя:
Online Availability
Compute
Network
Storage
Эти новые категории позволяют более органично охватывать проблемы сервера vCenter и упрощать управление им.
5. Улучшения Content Library.
Функции синхронизации шаблонов VM Template (VMTX).
Шаблоны виртуальных машин теперь можно синхронизировать в автоматическом режиме, как между приватными облаками с серверами vCenter, так и с публичным облаком VMware Cloud on AWS.
6. Улучшения vSphere Client.
В vSphere Client появилась возможность "code capture" (о ней мы писали вот тут). Теперь она позволяет вести запись пользовательских действий, которые были сделаны в рамках текущей сессии через vCenter API, и генерация соответствующего скрипта. Далее его можно использовать для автоматизации задач в инфраструктуре vSphere.
Функции API Explorer (доступны в разделе "Developer Center") - простая утилита по поиску в API, которая позволяет найти основные API-вызовы, включая примеры и возможность их тестирования.
7. Улучшения vSphere Update Manager.
Улучшения пользовательского интерфейса, включая функции attach, compliance check и remediation (все можно делать на одном экране).
Теперь можно привязать и сделать remediate для нескольких бейслайнов в рамках одной операции.
Во время remediation можно отключать removable-девайсы от виртуальных машин, включать Quickboot и пропускать проверки vSAN HealthCheck.
8. Улучшения VMware Tools.
Для Windows Server 2016 тулзы теперь обновляются через Windows update, а значит, что их обновления включены в общий цикл апдейта системы.
Версия VMware tools for Linux (в формате .TAR) больше не развивается, начиная с VMware Tools 10.3.10, так как OpenVM Tools доступны через любой package update manager.
9. Фикс Host Profiles.
Теперь при применении профиля хоста к ESXi не удаляется интерфейс VMK0, как это было раньше.
10. Улучшения безопасности.
Windows Server 2019 и RHEL 8 теперь полностью поддерживаются в vSphere 6.7 Update 2.
Можно применять лимиты для Password History и Reuse.
Теперь логируются дополнительные события SSO.
Улучшения ESXi certification API.
Генерация запроса vCenter Server CSR доступна через GUI клиента.
vSphere 6.7 Update 2 лучше обрабатывает уязвимости CPU за счет нового планировщика.
Доступна сертификация NIAP.
11. Улучшения производительности.
Поддержка 40 & 100Gb Ethernet и RDMA
Новая версия Virtual Hardware 15 (VM Compatibility):
До 256 vCPU на виртуальную машину
До 6 ТБ RAM на ВМ
Поддержка SAP HANA
На момент написания статьи обновление VMware vSphere 6.7 Update 2 было еще недоступно. Мы обновим пост, когда обновление можно будет скачать.
Совсем недавно мы писали о новых возможностях решения VMware NSX-T 2.4, которое предназначено для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров и контейнеров приложений.
Также у VMware есть продукт vRealize Network Insight, который позволяет системным и сетевым администраторам, а также администраторам информационной безопасности, следить за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.
Ну и, конечно же, многие из вас помнят решение AppDefense, анонсированное на VMworld 2017. Оно реализует новую модель защиты приложений в виртуализованных и облачных средах. Суть технологии AppDefense заключается в том, что она изучает нормальное поведение операционной системы и приложений при обычных условиях, а в случае выявления отклонений от этого состояния, оповещает об этом администратора и автоматически предпринимает некоторые шаги по защите окружения.
Использовав наработки этих трех продуктов за последние годы, компания VMware на днях анонсировала новое решение - первый в отрасли Service-defined Firewall.
Это решение основано на подходе по микросегментации приложений с точки зрения защиты виртуальной среды (см. service insertion и guest introspection), что подразумевает анализ сетевой активности на уровне приложения, при этом мониторинг ведется извне гостевой ОС на уровне гипервизора (данные берутся из NSX или напрямую с серверов ESXi), что позволяет исключить манипуляции средствами обнаружения вторжений, которые могут быть выполнены программным обеспечением внутри ОС.
Но главная штука VMware Service-defined Firewall - это возможность создания политик на уровне приложений/микросервисов, а не сетевых компонентов (серверов/ОС/портов). Это существенно упрощает ввод в эксплуатацию новых сервисов с точки зрения организации их защиты, а также обслуживания при перемещении виртуальных машин внутри датацентра и между ЦОДами.
Традиционная защита ИТ-инфраструктуры строится на базе обеспечения безопасности приложений, находящимися за сетевыми экранами, то есть защищается только сетевой периметр. При этом часто вектор атаки расположен внутри инфраструктуры, где вредоносное ПО сначала изучает ее состав и структуру, а потом начинает распространяться в датацентре, используя его уязвимые места.
VMware Service-defined Firewall позволит использовать новый подход к защите сетевой инфраструктуры предприятия за счет анализа приложений внутри периметра ЦОД (internal network firewalling), где наблюдение за сервисами происходит на уровне гипервизора и на седьмом уровне модели OSI (L7 packet inspection), без агентов в гостевых ОС, при этом используется модель Zero Trust (то есть изначально нет доверия ни одному компоненту в сети, считается, что атака может прийти откуда угодно, через любое сетевое соединение).
Суть защиты заключается в наблюдении за всеми приложениями датацентра, определении их "хорошего" поведения и далее детектировании отклонений от их повседневной активности, что влечет за собой оповещение администратора, который уже предпринимает действия по устранению угроз. При этом VMware Service-defined Firewall сам способен сгенерировать нужные политики для защиты приложений.
Такая модель обладает неоспоримым преимуществом перед системами с агентами, где вредоносное ПО может получить контроль над этими агентами. Также еще один плюс VMware Service-defined Firewall - это чисто программная реализация. В современном мире программно-аппаратные сетевые экраны сложно масштабируются, а также есть проблемы с управлением ими, так как приложение в виртуальной инфраструктуре может перемещаться между серверами и даже между датацентрами.
Для анализа подозрительных активностей используется Application Verification Cloud, который собирает информацию из миллионов виртуальных машин по всему миру и использует методы машинного обучения для определения нормального поведения микросервисов и их вариаций, а также выявления отклонений от нормальных показателей.
Что интересного можно почитать на тему VMware Service-defined Firewall:
Облачный провайдер «ИТ-ГРАД» повторно подтвердил статус поставщика управляемых сервисов. С обновленным статусом PCI DSS Managed Service Provider компания продолжит оказывать услуги по физическому размещению и аренде оборудования, включая аренду виртуальной инфраструктуры в модели IaaS с возможностью последующего управления и администрирования силами команды провайдера.
Наличие сертификата говорит о том, что облако «ИТ-ГРАД» полностью соответствует требованиям международного стандарта PCI DSS и гарантирует безопасное обращение платежных карт для организаций, использующих облачную площадку провайдера. Это дает право «ИТ-ГРАД» предоставлять услугу PCI DSS хостинга, благодаря которой клиент получает надежную, защищенную среду для обработки карточных данных и полную уверенность в отсутствии рисков финансовых потерь. Вместе с тем поставщик закрывает вопросы физической защиты серверов, администрирования ОС и обеспечивает постоянный контроль за безопасностью всех сегментов облачной ИТ-инфраструктуры.
На сайте проекта VMware Labs очередное интересное обновление - утилита Policy Enforcer. Она позволяет проверять пользовательские настройки политик на их машинах под управлением Workspace ONE и возвращать эти настройки к заданным параметрам.
Policy Enforcer проверяет политики Content Security Policy (CSP, политики защиты контента) в ОС Windows 10 на соответствие заданным в консоли Mobile Device Management (MDM) решения Workspace ONE, и, если пользователь их изменил через редактор реестра, возвращает их к нужным значениям ключей реестра.
Policy Enforcer можно развернуть на машинах пользователей с помощью MSI-пакета PolicyEnforcerInstaller.msi через консоль UEM (User Environment Manager) и установить как внутреннее приложение (internal app) в разделе Apps & Books (Applications > Native).
При развертывании этого сервиса настройку App delivery method нужно выставить в Auto.
Далее на машине пользователя специальная служба будет следить за изменением ключей реестра для политик MDM:
Скачать Workspace ONE Policy Enforcer можно по этой ссылке.
В 1981 году на экраны вышел культовый фильм Джорджа Миллера с участием Мела Гибсона «Безумный Макс: Воин дороги». Этот фильм принес в английский язык новый термин: «road warrior», которым стали называть сотрудников, чья работа требовала большого количества путешествий. Такие сотрудники должны были только время от времени приезжать в офис для выполнения административных задач вроде оформления отчета о расходах или получения информации о клиентах. По мере развития информационных и телекоммуникационных технологий сотрудникам уже не нужно было появляться в офисе – многие операции можно было выполнять дистанционно – сначала при помощи модема, затем, после развития Интернет – с помощью VPN-канала.
В наше время современные технологии позволяют выполнять офисную работу все большему количеству людей, не выходя из дома. По данным Eurostat, 35% предприятий в Европе в настоящее время предлагают своим сотрудникам возможность работать из дома.
Все более широкое использование дистанционных методов работы усложнило для организаций поиск оптимального баланса между безопасностью и удобством работы. Дело в том, что все выгоды, связанные с дистанционной работой, могут быть потеряны из-за недостаточной защиты.
Согласно исследованию Ponemon Institute средняя стоимость ущерба, связанного с нарушением безопасности, возросла с 3,62 млн. долларов в 2017 г. до 3,86 млн. долларов в 2018 г., то есть на 6,4 процента. Количество и сложность инцидентов, связанных с безопасностью, также возросли.
Как правило, серверы и компьютеры в офисе компании хорошо защищены при помощи программного и аппаратного обеспечения, и приложения, с которыми работают сотрудники компании, размещены внутри защищенного периметра.
Созданная внутренняя инфраструктура безопасности обслуживается не одним человеком, а целым департаментом, в котором каждый инженер занимается своим направлением. В классическом сценарии, все управление web-безопасностью сконцентрировано в головном офисе, и весть трафик настроен на прохождение через единый шлюз.
С приходом GDPR многие компании поменяли свои политики конфиденциальности и реализовали дополнительные механизмы работы с персональными данными пользователей. Но ряду организаций сделать это не удалось, и им пришлось свернуть бизнес. Посмотрим, почему так получилось.
Первая реакция бизнесов на GDPR
Одним из самых серьезных требований нового регламента стал запрет использовать персональные данные (ПД) в рекламных целях без согласия пользователей. Поэтому многие ИТ-компании изменили политики работы с ПД.
Например, в Facebook добавили новое диалоговое окно с просьбой дать согласие на обработку той или иной информации (в том числе в маркетинговых целях). Однако интерфейс этого окна подвергся критике общественности – о нем писали даже такие крупные издания, как TechCrunch и The Guardian. Журналисты отметили, что дизайн окна намеренно подталкивает пользователей предоставить социальной сети максимум данных: кнопка для изменения настроек крайне неприметна, а ограничить использование тех или иных данных не так-то просто.
Facebook также предоставили возможность выгружать историю поиска в социальной сети и другие данные: историю обновления статусов и звонков, а также теги местоположений и др. Это еще одно требование GDPR.
Такую же функцию предоставила «дочка» Facebook – Instagram. Пользователь получает архив с фотографиями, информацией профиля, комментариями и др.
Однако не всем бизнесам удалось подружиться с новыми требованиями регламента. К 25 мая, когда начал действовать GDPR, больше половины европейских IT-компаний не внедрили необходимые механизмы для работы с ПД. И таких компаний все еще большинство. Поговорим о том, с чем это связано.
Почему сложно выполнять требования GDPR
Это дорого. По данным исследований, только компании из Fortune 500 и FTSE 100 потратят почти миллиард евро на пересмотр своих контрактов и приведение их в соответствие с требованиями GDPR. У малого и среднего бизнеса на проработку нового регламента ресурсов зачастую просто нет.
Регламент не учитывает законы отдельных стран. У разных стран разные определения персональных данных. Поэтому многие формулировки в GDPR сделаны максимально обтекаемыми.
В законе плохо прописана работа с машинным обучением. GDPR начали разрабатывать в 2016 году и многие заложенные в него концепции уже успели устареть. В частности, в нем плохо описаны принципы работы с большими данными (полученными на основе ПД) и системами искусственного интеллекта.
По закону разработчик должен понимать, почему интеллектуальная система приняла то или иное решение. Требование регламента – объяснить пользователю, как именно обрабатываются его персональные данные. Однако «заглянуть» внутрь алгоритма не всегда возможно, так как в большинстве случаев система ИИ представляет собой черный ящик: на вход подаются данные, они как-то обрабатываются, а на выходе получается результат. Даже создатель системы может не знать, почему она выдала такое решение.
Кто не справился и закрылся
Из-за сложности (и дороговизны) реализации всех требований GDPR компании, которые не располагали достаточными ресурсами, были вынуждена прекратить деятельность. О закрытии объявил ряд онлайн-игр: Super Monday Night Combat и Loadout. В обоих случаях стоимость внедрения всех систем для соответствия регламенту (обновление клиента, БД и покупка новых серверов) оказалась неподъемной для небольших студий. В случае с Super Monday Night Combat стоимость обновления вообще была...Читать статью далее->>
Совсем недавно стало известно о трех очень серьезных багах в платформе VMware vSphere, которые затронули, как платформу vSphere 5.x/6.x, так и средство создания отказоустойчивых хранилищ для виртуальных машин VMware vSAN 6.6/6.7.
1. Повреждение данных виртуальных дисков снапшотов формата SEsparse.
Начиная с VMware ESXi 5.5, диски стапшотов виртуальных машин стали создаваться в формате SEsparse. Такой диск создается в ESXi 5.5 если диск машины более 2 ТБ, а начиная с ESXi 6.0 / VMFS6 - он используется для снапшотов всех машин. Так что под угрозой практически все виртуальные машины со снапшотами. А ведь снапшоты используются всеми ВМ, для которых применяется резервное копирование через механизм vSphere API for Data Protection (например, с помощью продукта Veeam Backup and Replication).
Ну а суть бага заключается в том, что блоки данных могут оказаться поврежденными, что приводит к неконсистентности файлов для приложений (например, баз данных), а также иногда к невозможности загрузки виртуальной машины!
Баг и возможные способы решения описаны в KB 59216. В vSphere 6.7 Update 1 баг уже пофикшен. Для остального есть следующие апдейты:
Для ESXi 5.5 обновления нет, но вы можете отключить функцию "IO coalescing" для формата дисков SEsparse. Делается это следующей командой:
esxcli system settings advanced set -i 0 -o /COW/COWEnableIOCoalescing
2. Проблема консистентности виртуальных дисков машин на платформе vSAN 6.6.
Аналогично багу из прошлого пункта, здесь может произойти неприятность с целостностью данных виртуальных машин, которые работают в кластере хранилищ VMware vSAN 6.6. Это может случиться в следующих обстоятельствах:
vSAN начинает процесс ресинхронизации
В этот момент вы расширяете диск VMDK виртуальной машины
vSAN снова начинает ресинхронизировать уже расширенный диск виртуальной машины
Проблема описана в KB 58715. В этом случае вы сможете только восстановить консистентность виртуальных машин, но сами данные приложений вы уже не вернете.
3. Получение доступа root к хосту ESXi из виртуальной машины.
Если вы используете виртуальные машины с драйвером сетевого адаптера vmxnet3 (у него был еще один отдельный баг), то для непропатченных хостов есть возможность получения доступа root к шеллу ESXi из виртуальной машины.
Кстати, это было публично показано впервые:
#GeekPwn2018 Chaitin Tech security researcher f1yyy has escaped VMware EXSi and got root shell on the host for the first time in the world. After demonstrating it at GeekPwn 2018, f1yyy received the Best of Tech Award and was selected to the GeekPwn Hall of Fame.@GeekPwnpic.twitter.com/2Y2kYKaw4d
Информация об этой уязвимости опубликована в VMware advisory VMSA-2018-0027. Там же есть и названия необходимых вам патчей (обратите внимание, что багу подвержены также и платформы Workstation / Fusion).
RSS
